Is this branch name still intended to be edly-io/*?

I've reverted the branch name and made updates. Could you please review it?

An issue I want to highlight when executing npm run snapshot, where the tests fail due to the following error.

/Users/hina/mfes/frontend-component-footer/node_modules/@openedx/frontend-plugin-framework/node_modules/@edx/frontend-platform/index.js:1
    ({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,global,jest){export { modifyObjectKeys, camelCaseObject, snakeCaseObject, convertKeyNames, getQueryParameters, ensureDefinedConfig, parseURL, getPath } from './utils';
                                                                                             ^^^^^^

    SyntaxError: Unexpected token 'export'

       7 | import { Image } from '@edx/paragon';
       8 | import { getConfig } from '@edx/frontend-platform';
    >  9 | import { PluginSlot } from '@openedx/frontend-plugin-framework';
         | ^

Agh, my guess is that Jest is not handling the import statement within frontend-plugin-framework's Frontend Platform dependency for some reason. I've not seen this be an issue with other React repos, and I'm not sure what the best solution is for this, but I did notice that when npm run test is ran it shows this message:

Jest encountered an unexpected token

This usually means that you are trying to import a file which Jest cannot parse, e.g. it's not plain JavaScript.

By default, if Jest sees a Babel config, it will use that to transform your files, ignoring "node_modules".

Here's what you can do:
 • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/en/ecmascript-modules for how to enable it.
 • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
 • If you need a custom transformation specify a "transform" option in your config.
 • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

You'll find more details and examples of these config options in the docs:
https://jestjs.io/docs/en/configuration.html

from the changes you made already, should this still be here?

Yes, the plugin is designed to display footer links by default upon installation. Since it is not separately available on npm, that's why included it like that .If there will be a requirement to hide these links, users have the flexibility to do so using the env.config.js file. Or Is there any better way to handle this, we can go ahead with that?

With frontend-plugin-framework, the plugins don't have to be installed as separate npm packages though. Since the source files are already part of this repository, you can just specify the plugin path using the config file. At least, that's how I thought it worked.

That's right @bradenmacdonald ! I've been importing a component purely from the local path needed to fetch it from the repo, but I've also seen a configuration in Learning MFE to do some aliasing of the plugins, which I imagine would help in the case where we want to clearly mark a component's purpose as being a "plugin".

With that, I don't think this package.json approach is necessary.

Makes sense. I also got the idea of aliasing of plugins from course-authoring MFE. I've removed it. Also, I want to ask are we going to include links in footer? I've read that ADR and that's why included the footer-links.

I think this format is a little too prescriptive. We shouldn't be including a tutor logo/slot by default, because not everyone uses Tutor to deploy it. And this kind of assumes there will be either two logos, one logo, or none. What would be much more flexible is something like this:

        <PluginSlot as="footer" id="mfe-global-footer" className="footer border-top py-3 px-4" role="contentinfo">
            <PluginWidget id="default-poweredby-logo"><a ...><img ... /></a></PluginWidget>
            <PluginWidget id="language-selector">...</PluginWidget>
            <PluginWidget id="copyright-text">...</PluginWidget>
        </PluginSlot>

And then for your Tutor plugin, in the config you have something like:

1. Hide the default-poweredby-logo widget.
2. Insert the new poweredby-tutor-openedx widget before the default-poweredby-logo widget.

But @jsnwesson is it possible to define several default widgets in one slot like this with the plugin framework?

Plugin Framework currently does not have any component named PluginWidget. In the latest commit, I've added PluginSlot instead of PluginWidget. Can you please check again?
Furthermore, on what basis, we are going to decide whether we have to use PluginSlot or PluginWidget (if it will be added in plugin framework)?
What I understand is that a list is PluginSlot for example, and its items will be Widgets. Here, in footer, all are different elements (logo, lang selector, copyright) and not list. Then, why are we treating them like widgets? Any point which I'm missing.

Hi,
Would like to hear the concerns from your side.

Hi @hinakhadim and @bradenmacdonald , huge apologies for the delay in response!
I think one of the confusions here was the naming convention differences between Braden's UI Plugin approach and Frontend Plugin Framework's ("FPF").

• In FPF, there are only PluginSlots, not PluginWidgets (and there is no plan to bring that name into the library for any use case).
• FPF takes Braden's UI approach of using PluginOperations to define what widgets will go into the PluginSlot as defined by the env.config.js file.
• Lastly, and possibly most importantly, any content inside a PluginSlot is considered the defaultContent. That defaultContent is treated as one children body and can either be included or hidden in production by modifying the keepDefault attribute for that PluginSlot via env.config.js. (Source)

And to confirm with you @hinakhadim , I noticed that inside the "parent" PluginSlot with the id mfe-global-footer, I see that it has four PluginSlots as part of its defaultContent body.
Is the desire here so that each of those four "child" PluginSlots can be modified in the env.config.js, or was it there a misunderstanding around if they each needed to be wrapped by a PluginSlot?
For example, if you didn't want to customize each individual component in the defaultContent of the "parent" PluginSlot, you could rewrite this as:

<PluginSlot as="footer" id="mfe-global-footer" className="footer border-top py-3 px-4" role="contentinfo">
  <a
    className="d-block"
    href={config.LMS_BASE_URL}
    aria-label={intl.formatMessage(messages['footer.logo.ariaLabel'])}
  >
    <img
      style={{ maxHeight: 45 }}
      src={logo || config.LOGO_TRADEMARK_URL}
      alt={intl.formatMessage(messages['footer.logo.altText'])}
    />
  </a>
  <FooterLinks />
  {showLanguageSelector && (
    <LanguageSelector
      options={supportedLanguages}
      onSubmit={onLanguageSelected}
    />
  )}
  <span className="copyright-site mt-2">{intl.formatMessage(messages['footer.copyright.text'])}</span>
</PluginSlot>

@hinakhadim @jsnwesson Sorry for the confusion. I was hoping there would be some way to have multiple widgets in a plugin slot in FPF. It seems like is it possible if you define it in a config, but it's not currently possible to define multiple widgets as the default content without setting a config override.

I do feel that for a use case like this, it's nice to have several default widgets in one slot, but you could either just create them as several slots inside a bigger slot or one slot with one default content that is completely overwritten by a plugin even though that may cause a lot of duplicate code.

Is the desire here so that each of those four "child" PluginSlots can be modified in the env.config.js, or was it there a misunderstanding around if they each needed to be wrapped by a PluginSlot?

@jsnwesson My thinking was that when someone wants to change only logo, they can target the logo PluginSlot. if someone doesn't require this footer and wants to introduce their own they can target the parent PluginSlot.

As @bradenmacdonald said previously, giving option for only one bigger slot causes lot of duplications. Someone wants to change logo has to completely override the whole footer component which causes frustration. What are your thoughts, Jason?

Knowing that this PluginSlots within a PluginSlot implementation is intentional, I think it works! My team has a similar thing in mind for the Course List module in Learner Dashboard MFE.

@bradenmacdonald if having a package.json for a /plugins directory in your Course Authoring plugins, I'm assuming this isn't needed any longer now that FPF would allow for the components to be plugged in using DirectPlugin. Just wanted to get a confirmation that this is probably a remnant of a different plugin approach.

@jsnwesson The pluggable "Pages & Resources" section of Course Authoring uses a different plugin approach which still uses package.json files for each plugin. But I don't think it's needed here, nor with FPF in general.

Yes, this is no longer needed now as I am importing FooterLink from path.